The present invention is directed to measuring response time between end points in a computer network. FIG. 1 is a schematic block diagram of a conventional computer network that includes a local enterprise network coupled to a remote enterprise network via an Internet Service Provider (ISP) domain. The local and remote enterprise networks may comprise autonomous systems such as corporate intranets, where in the local enterprise network includes a source end station ESA and the remote enterprise network includes a destination end station ESB. The ISP domain includes a plurality of routers coupled together by a transmission control protocol/Internet protocol (TCP/IP) network cloud. As shown in FIG. 1, the ISP domain includes a source router 100 (SRC) and a destination router 102 (DSTN) bordering an IP network cloud 104 and interconnected thereto by associated edge routers 103 and 105.
During operation, a user of source end station A (ESA) 106 may realize delays when communicating with destination end station B (ESB) 108 over the ISP domain. The delays may occur in the local enterprise network, the remote enterprise network or at the intermediate ISP domain. Typically, the user will levy a complaint to the Internet service provider and it would desirable for the Internet service provider to diagnose its domain and unequivocally determine whether it is the source of the delays.
Typically, an Internet Control Message Protocol (ICMP) is used to measure response time between end points, such as the source router and destination router, in the ISP domain. The ICMP is described generally on pages 185-189 of the textbook Interconnections by Radia Perlman, Addison Wesley Longman, Inc., 1992. In addition, the industry standards hand out entitled xe2x80x9cstandard RFC 792xe2x80x9d describes the Internet Control Message Protocol in detail. The basic format of an ICMP message consists of one byte of message type, one byte of code, two checksum bytes, two bytes of type-specific data, followed by the variable Internet header itself and 64 bits of the problem packet. ICMP message types include: 0=echo reply; 3=destination unreachable; 4=source quench; 5=redirect; 8=echo request; 11=time exceeded; 12=parameter problem; 13=timestamp request; 14=timestamp reply; 15=information request; 16=information reply; 17=address mask request; and 18=address mask reply. The ICMP code message includes: (where type is time exceeded) 0=died in transit and 1=died while being reassembled at the destination; or (where type is destination unreachable) 0=network unreachable; 1=host unreachable; 2=protocol unreachable; 3=port unreachable; 4=fragmentation required but not allowed; and 5=source failed; or (where type is parameter problem) code unused.
The timestamp process entails the request and transmission of time data associated with message receipt. For example, an originate timestamp message is put in by the requester to indicate the most recent known time before transmission of the timestamp request. A receive timestamp message is put in by the replier to indicate the time that the request was received. A transmit timestamp message is put in by the replier to indicate the time at which the reply was transmitted.
The particular type of ICMP message used to measure response time is the echo request (message type=8), which can be used to decide whether some destination is reachable. The destination receiving an echo request is supposed to respond with an echo reply (message type=0). The echo request is also known as a xe2x80x9cPing.xe2x80x9d To ping a network node means to send an echo request thereto. Ping message exchanges, and the ICMP protocol, are typically used to measure response time because that protocol and those messages are services readily available to all devices in a TCP/IP network. That is, ICMP is an integral part of the Internet Protocol (IP) and implemented by every IP module in any IP device. Ping is an operation based on ICMP, and thus, is available on all machines. Therefore, Ping messages are typically used to measure response time in an ISP domain in response to customer complaints with respect to service.
A disadvantage associated with the use of Ping messages as a means for measuring network response time in the ISP domain is that the ICMP is not representative of the client""s application protocol that manifests the latencies/delays. For example, the customer may be running a Domain Name Service (DNS) or a Simple Network Management Protocol (SNMP) application when they latencies manifest. These application protocols typically run over a transport such as the User Datagram Protocol (UDP). Another application may be the Hypertext Transfer Protocol (HTTP) that generally runs over the Transmission Control Protocol (TCP) transport of the Internet Protocol (IP) stack. In general, there are more latencies associated with the UDP and TCP protocol communications because of the processing required in the end points when implementing such features as quality of service (QOS). Therefore, it is desirable to measure the response time between router end points in the ISP domain using a protocol that is similar to the protocol used by a customer, such as UDP or TCP.
When using these transport protocols to communicate with a destination, the source end station generally specifies a particular port in the destination for receiving and responding to a request from the source. In order to effect such transport protocol communication, certain software processes must be running on the destination end station. Typically, the destination end station is a server located in the remote enterprise network and the source end station is a client located in the local enterprise network. The software running on the server that is required to effect transport communication is typically a server process (otherwise known as a responder) that is configured to xe2x80x9clistenxe2x80x9d on a particular port in order to receive requests from the client. For example, in the case of a DNS application running over EDP, the DNS server process running on a destination end station listens on standard router Port 53 in order to service any DNS requests.
The responder server processes are generally not running on the destination in source routers in the ISP domain. Yet in order for the Internet Service Provider to accurately diagnosis the response time in its domain, it is desired for the ISP to emulate the UDP transaction between the source and destination routers in the ISP domain. That way, the ISP can determine whether there is any latencies between the source and destination router end points that are configured to utilize the same protocol, quality of service and ports as the client and server end stations on the local and remote enterprise networks. Accordingly, the server process software must be installed on the destination router so that the destination router can respond to the service request using the UDP transport protocol. More specifically, if the client is having a problem on, for example, Port 53, it is desirable to emulate Port 53 on the destination of the ISP domain. The server process (responder software) must be running and listening on Port 53 in the destination router in order to respond to the UDP request from the source router in the ISP domain.
A problem with manually configuring the routers with the appropriate software is that these processes would be constantly running in the routers for an extended period of time; this could lead to disruption of service (denial of service attacks) on the routers by unauthorized interlopers, e.g. xe2x80x9chackers.xe2x80x9d The present invention is directed to solving this problem and, in particular, to a technique for dynamically invoking a responder process on a destination router of the ISP domain.
The present invention is directed to a control mechanism that enables a destination router to authenticate response time requests issued by a source router before providing the requests to service software for processing. The control mechanism comprises a Network Endpoint Control Protocol (NECP) message format that is exchanged between the source and destination routers when measuring response time throughout the network. The NECP message format encapsulates a Command Length Status Data (CLSD) message that actually holds the response time requests.
Specifically, a NECP control protocol message is generated by a xe2x80x9cclientxe2x80x9d source router and transmitted to a xe2x80x9cserverxe2x80x9d destination end router to, among other goals, begin listening on a particular port. For purposes of the present invention, the source router entity is called a xe2x80x9ccollectorxe2x80x9d and the destination router entity is called a xe2x80x9cresponder.xe2x80x9d Preferably, there are responder xe2x80x9cdaemonxe2x80x9d processes running in various routers of the ISP domain, e.g. all edge routers. Broadly stated, the collector issues an NECP control message to the responder, instructing the responder to listen on a particular port (e.g. Port #53). The control message also includes a request for the responder to initiate a server process running the UDP protocol and, of course listening on Port 53. Note that there is a default port that the responder is initially configured to listen on to receive the NECP control message. In the illustrative embodiment described herein, the default port is referred to as a xe2x80x9cresponder portxe2x80x9d and has a port number 1967. If there is a responder configured on the destination router, the responder receives the control message request and starts up a UDP server process configured to listen on Port 53. The client request may further specify a time interval (e.g. 30 seconds), within which the UDP port will be enabled. That is, the novel protocol enables specification of a discrete time period during which the UDP server is running on a particular port to thereby obviate misuse by intruders. Furthermore, in order to insure authentication of the message exchange, the entire NECP control message may be converted into a secure form using a particular encryption, scrambling or hashing algorithmxe2x80x94for example, the conventional MD5 hashing checksum algorithm. According to the invention, such encryption is optional. Therefore, an encryption enabler function is provided to configure the responder for receiving encrypted messages. If it is so enabled, the responder port is pre-configured with an appropriate key to decrypt/verify the message according to the MD5 algorithm.
Note that the control message can specify either a UDP port or a TCP port on which the responder should listen. In the case of a UDP port request from the collector, the responder replies with the UDP (probe entering packet returned to the collector). If the request is to listen on a TCP port, the responder accepts the incoming TCP connection. Note also that if the encryption authentication mechanism is not enabled, the responder will utilize conventional Access Control Lists (ACL) in, for example, look-up table format, to determine whether or not a particular client is authorized to transmit on the port 1967. In addition, the specified time interval within the control message should be sufficient to enable response time measurements between the collector and responder.
In summary, a collector will issue a novel control message to a responder over a default responder port in accordance with the present invention. If the responder is enabled for encryption communication, it will decrypt the control message according to the specified key and algorithm. If the responder is not so configured, it will check a conventional ACL to determine whether the client is authorized to communicate with the server. If the client is authorized or if the message is successfully decrypted, the responder interprets the message as instructions for starting up a particular port according to a particular protocol (TCP or UDP) and for a specified time period. The responder then responds to the collector in a manner dependent upon the particular protocol. In the case of a request to enable a UDP port for a particular time period, the responder processes a request and then sends back an acknowledgment to the collector. The collector receives the acknowledgment and then sends out a UDP probe packet to the responder. The responder then xe2x80x9cechoesxe2x80x9d the packet back to the collector, which keeps the result. In the case of enabling a TCP port connection, instead of sending a UDP probe packet, the collector sends a TCP connect probe packet to establish a TCP connection to the destination router. A TCP connect probe measures the time for the connection to be established and completed, and essentially, measures xe2x80x9cvirtual circuitxe2x80x9d availability. In either case, the responder disables the port after it replies to the probe packet. In addition, the responder disables the port when the response period expires. The disabling feature of the present invention is a security measure intended to prevent unauthorized use of a responder port.